Hypertext began life with Ted Nelson's Project Xanadu. From the outset, Project Xanadu was intended to include mechanisms for levying very small fees for viewing content: “Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies (‘transclusions’) of all or part of the document.” HTML and HTTP currency include no such mandatory, universal payments scheme, though the HTTP 402 Payment Required error code is reserved to allow specialist schemes to be established.
A number of payment schemes have been proposed and businesses launched to address micropayments for HTTP: most have failed and so far none has made substantial inroads into the web at large. Apart from Face book Credits (which is not usable in the internet at large), no general-purpose micropayments scheme has emerged for application developers.
Users may be willing to pay money to use a website, application or service, but may object to the annoyances of advertising or the inconvenience of tipping or subscribing to multiple providers. A centralised model offering convenience, security and automation would allow the user to meet these constraints. One such model would be to pay a fixed amount to some third-party service, which would then distribute funds on their behalf to different websites, applications and services according to some formula based in part on usage.
Because this approach melds features of micropayment and subscriptions, the term ‘microsubscription’ is used to describe it.
An example company that might be characterised as a microsubscription service is called ‘Kachingle’. Another three other companies have previously operated in this area: ‘Readability’ (subsequently shot down), ‘Contenture’ (subsequently shut down) and ‘In-a-Moon’ (which has apparently been inactive since August 2010). A company called ‘Flattr’ operates a micropayments service on a slightly different model.
All these services use a ‘2-party protocol’ to authenticate that the user has accessed content (e.g. a web page) from a given content provider, or elected to make a micropayment to a given content provider.
The parties in a 2-party protocol are the user browser and a tracking server. The user browser requests some tracking resource (including sending any relevant cookies) from the tracker server. The tracker server may attach cookies to the response.
In the 2-party protocol the publisher's role is merely to embed some code or a URL provided by the tracking service. It might be a “web bug” or some Javascript that issues an independent request to the tracking server.
The publisher relies on the tracking server to provide a reliable account of visitors to their website.
The naive 2-party protocol and its variants have been widely used on the Internet, for example, by Google Analytics, for visit-tracking purposes. But the introduction of payments relating to visits by users creates a fiscal incentive for malicious users to subvert the protocol, so as to direct undeserved payments by indicating more visitors have used their website, application or service than have actually done so.
As will be appreciated by a person skilled in the art, the 2-party protocol is subversible by publishers because it relies on embedding supplied code or pointing to a URL hosted by the tracker. This scheme is firstly vulnerable to man-in-the-middle attacks. There is also no assurance that the publisher will provide the link, code or resource. For instance, a publisher can simply pose as the browser, fetch javascript from the tracking service to extract any embedded nonces and cookies, and then serve its own malicious javascript to the end user. This is a problem with all 2-party protocols that rely on embedded pure HTTP requests or on Javascript—there is no guarantee that any resource requests came from the user and there is no guarantee that any code provided for execution by the client is trustworthy.
The 2-party protocol is inherently insecure. This undermines the confidence of users of the system, in that their micropayments or share of a larger subscription fee may not be directed to the party that they intended; and it undermines the confidence of providers that they will receive payment proportional to usage of their services by users.
It is thus desirable to overcome, or at least ameliorate, the security vulnerabilities of the current tracking protocols used by the micro-subscription service providers, to avert criminal or fraudulent activities by persons seeking to subvert such systems for fiscal gain.
The preceding discussion of the background art is intended to facilitate an understanding of the present invention only. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was part of the common general knowledge as at the priority date of the application.
In example embodiments, a computer system (e.g., a standalone, client or server computer system) configured by an application may constitute a “module” that is configured and operates to perform certain operations in other embodiments, the “module” may be implemented mechanically or electronically; so a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor) to perform certain operations A module may also comprise programmable logic or circuitry (e.g. as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a module mechanically, in the dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g. configured by software) may be driven by cost and time considerations. Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein.
Throughout the specification unless the context requires otherwise, the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
Throughout the specification unless the contest requires otherwise, the word “include” or variations such as “includes” or “including”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
The term ‘predetermined steps’ or ‘predetermined sequence of steps’ refers broadly to an agreed protocol comprising two or more steps that must be completed in a set order. For example, during a TCP/IP handshake between two network devices, a series of predetermined steps must be followed, i.e. Host A sends a TCP SYNchronize packet to Host B; Host B receives A's SYN: Host B sends a SYNchronize-ACKnowledgement; Host A receives B's SYN-ACK; Host A sends ACKnowledge; and finally Host B receives ACK. If these predetermined steps are corrected followed, the TCP socket connection is ESTABLISHED.
The preferred embodiment was named the ‘Robojar Protocol’ during the development phase of the invention, denoting a computer-based system that tracks small contributions from a user to a resource provider. The use of the term ‘Robojar Protocol’ in the description and drawings, and the content of the headings in this specification, are provided for convenience to assist the reader, and they are not to be interpreted so as to narrow or limit the scope of the disclosure in the description, claims, abstract or drawings.